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Abstract 


The  dataflow  interchange  format  (DIF)  is  a  textual  language  that  is  geared 
towards  capturing  the  semantics  of  graphical  design  tools  for  DSP  system  design. 
A  key  objective  of  DIF  is  to  facilitate  technology  transfer  across  dataflow-based 
DSP  design  tools  by  providing  a  common,  extensible  semantics  for  representing 
coarse-grain  dataflow  graphs,  and  recognizing  useful  sub-classes  of  dataflow  mod¬ 
els.  DIF  captures  essential  modeling  information  that  is  required  in  dataflow-based 
analysis  and  optimization  techniques,  such  as  algorithms  for  consistency  analysis, 
scheduling,  memory  management,  and  block  processing,  while  optionally  hiding 
proprietary  details  such  as  the  actual  code  that  implements  the  dataflow  blocks. 
Accompanying  DIF  is  a  software  package  of  intermediate  representations  and  algo¬ 
rithms  that  operate  on  application  models  that  are  captured  through  DIF.  This  paper 
describes  the  structure  of  the  DIF  language  together  with  several  implementation 
and  usage  examples. 

1.  Introduction 


Modeling  of  DSP  applications  based  on  coarse-grain  dataflow  graphs  is 
widespread  in  the  DSP  design  community,  and  a  large  and  growing  set  of  DSP 
design  tools  support  such  dataflow  semantics  [2],  Since  a  variety  of  dataflow  model¬ 
ing  styles  and  accompanying  semantic  constructs  have  been  developed  for  DSP 
design  tools  (e.g.,  see  [1,  4,  5,  8,  12,  13]),  a  critical  problem  in  the  process  of  tech¬ 
nology  transfer  to,  from,  and  across  such  tools  is  a  common,  vendor-independent 
language,  and  associated  suite  of  intermediate  representations  and  algorithms  for 
DSP-oriented  dataflow  modeling.  This  paper  describes  our  first  version  of  a  data- 
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flow  interchange  format  ( DIF)  for  addressing  this  problem. 

As  motivated  above,  DIF  is  not  centered  around  any  particular  form  of  data¬ 
flow,  and  is  designed  instead  to  express  different  kinds  of  dataflow  semantics.  Our 
present  version  of  DIF  includes  built-in  support  for  synchronous  dataflow  (SDF) 
semantics  [12],  which  have  emerged  as  an  important  common  denominator  across 
many  DSP  design  tools  and  support  powerful  algorithms  for  analysis  and  software 
synthesis  [3].  DIF  also  includes  support  for  the  closely  related  cyclo-static  dataflow 
(CSDF)  model  [4],  and  has  specialized  support  for  various  restricted  versions  of 
SDF,  in  particular,  homogeneous  and  single-rate  dataflow,  which  are  often  used  in 
multiprocessor  scheduling  and  hardware  synthesis.  Additionally,  support  for 
dynamic,  variable-parameter  dataflow  quantities  (production  rates,  consumption 
rates,  and  delays)  is  provided  in  DIF.  DIF  also  captures  hierarchy,  and  arbitrary  non¬ 
dataflow  attributes  that  can  be  associated  with  dataflow  graph  nodes  (also  called 
actors  or  blocks ),  edges,  and  graphs. 

2.  The  Language 


DIF  is  designed  to  be  exported  and  imported  automatically  by  tools.  How¬ 
ever,  unlike  other  interchange  formats,  DIF  is  also  designed  to  be  read  and  written 
by  designers  who  wish  to  understand  the  dataflow  structure  of  applications  or  the 
dataflow  semantics  of  a  particular  design  tool,  or  who  wish  to  specify  an  application 
model  for  one  or  more  design  tools  using  the  features  of  DIF.  Indeed,  DIF  provides 
the  programmer  a  unique,  integrated  set  of  semantic  features  that  are  relevant  to 
dataflow  modeling.  As  a  result,  DIF  is  not  based  on  XML,  which  is  more  for  pure 
data  exchange  applications,  and  is  not  well-suited  for  being  read  or  written  by 
humans.  Due  to  the  emphasis  on  readability,  DIF  supports  C/Java-style  comments, 
allows  specifications  to  be  modularized  across  multiple  files  (through  integration 
with  the  standard  C  preprocessor),  and  is  based  on  a  block-structured  syntax. 

A  dataflow  graph  definition  in  DIF  consists  in  general  of  six  blocks  of  code: 
topology,  interface,  refinement,  user-defined  and  built-in  attributes,  and  parameters . 
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These  code  blocks  are  contained  in  a  main  block  defining  the  dataflow  graph.  Note 
that  each  block  is  optional  without  violating  language  basics.  Using  the  basedon 
keyword,  a  graph  can  inherit  the  same  topology  as  another  graph  while  overriding 
arbitrary  attributes  and  parameters.  Figure  1  illustrates  the  general  form  of  a  graph 
definition  block.  The  optional  keyword  on  the  first  line  denotes  the  type  (fonn  of 
dataflow).  Further  details  on  the  different  graph  types  available  are  described  in  Sec¬ 
tion  3. 

2.1  Defining  the  Topology  of  a  Dataflow  Graph 

The  topology  definition  of  a  graph  consists  of  node  and  edge  definition 
blocks  (nodes  and  edges).  These  define  the  sets  of  nodes  and  edges,  and  associate  a 
unique  identifier  with  each  node  and  each  edge.  Since  dataflow  graphs  are  directed 
graphs,  edges  are  specified  by  their  source  and  sink  node  identifiers.  A  node  defini¬ 
tion  may  also  include  a  port  association  (described  further  in  Section  2.2)  for  inter¬ 
facing  to  other  graphs.  The  lower  left  side  of  Figure  3  shows  an  example  of  a 
topology  definition  block. 

2.2  Hierarchical  Graphs 

Given  the  importance  of  hierarchical  design  in  graphical  design  tools,  a  nec¬ 
essary  feature  of  the  DIF  language  is  the  general  ability  to  associate  a  node  of  a 
graph  with  a  “nested”  subgraph.  Such  hierarchical  nodes  are  called  supernodes  in 
DIF  tenninology.  In  addition  to  providing  for  hierarchy,  this  supemode  feature 
allows  for  reuse  of  graph  specifications:  a  topological  pattern  that  appears  multiple 
times  in  a  graph  can  be  defined  as  a  separate  graph  and  every  occurrence  in  the  orig¬ 
inal  graph  (parent  graph)  or  in  multiple  graphs  can  be  replaced  with  a  single  node. 

A  graph  can  be  declared  as  a  nested  subgraph  in  the  refinement  block  of  a 
parent  graph.  For  a  graph  to  be  declared  as  a  subgraph,  it  should  have  an  interface 
block,  which  includes  a  list  of  directed  ports.  A  port  will  then  be  associated  either 
with  a  node  (in  the  topology  block)  or  with  one  of  the  ports  of  a  supernode  (in  the 
refinement  block). 

Figure  2  gives  a  detailed  example  of  the  hierarchy  mechanism  in  DIF. 
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[#include  filename. dif] 

[keyword]  graph  graphID  [basedon  graphID ]  { 

params  { 

param  prm  1,  prm2, 
domain  ( prml ,  {1,  2,  ...}); 
domain  ( prm2 ,  [1 , 5]); 


interface  { 

input  portID,  portID, 
output  portID,  portID, 

} 

topology  { 

nodes  { nodelD[\portlD ],  nodelD[\portlD ],  ...} 
edges  { 

edge  ID  sourceNodelD  sinkNodelD ; 
edgelD  sourceNodelD  sinkNodelD ; 

} 

} 

refinement  { 

subgraphID  nodelD 

subPortID-.edgelD,  subPortID-.PortID, 
subgraphID  nodelD 

subPortID-.portID,  subPortID-.edgelD, 

} 

attribute  attributeName  { 
edgelD  value; 
nodelD  value; 


} 

[built-in  attribute ]  {...} 
[built-in  attribute ]  {...} 


} 

Figure  1 .  A  sketch  of  a  dataflow  graph  definition  in  DIF.  Items  in  boldface  in  this  fig¬ 
ure  and  throughout  the  paper  are  DIF  keywords.  Italicized  words  are  to  be  defined 
by  the  user.  Parts  in  square  brackets  are  optional. 
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graph  Graph  1  { 


interface  { 

input  PI,  P2; 

} 

topology  { 

nodes  {nl  :P1 ,  n2:P2} 


Figure  2.  (a)  (b)  Definition  of  DIF  graphs  with  interfaces  and  supernodes.  A  dashed 
line  means  a  port  association.  The  refinement  expression  in  Graph2  specifies  that 
node  n4  will  be  associated  with  Graphl  connecting  edge  e3  and  port  P3  to  ports  PI 
and  P2  of  Graphl  respectively.  Note  that  the  direction  of  each  connection  element 
(a  port  or  an  edge)  should  match  the  direction  of  the  port  that  it  is  connected  to.  (c) 
The  result  after  flattening  the  supernode  (n4)  in  Graph2. 
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2.3  User-defined  and  Built-in  Attributes 

DIF  supports  assigning  attributes  to  nodes,  edges,  and  graphs.  There  are  two 
types  of  attributes:  user-defined  and  built-in.  User-defined  attributes  are  attributes 
with  arbitrary  names  that  can  take  on  any  value  assigned  by  the  user.  Built-in 
attributes  are  pre-defined  attributes,  which  have  associated  keywords  in  the  DIF  lan¬ 
guage,  and  are  usually  handled  in  a  special  way  by  the  compiler.  Depending  on  the 
particular  semantics  of  a  design  tool  and  the  type  of  the  graph,  a  compiler  might 
read  built-in  attribute  values  into  special  fields  of  the  graph-related  data  structures, 
and  it  may  perform  checks  on  the  values  to  see  if  they  are  acceptable  (e.g.,  positive¬ 
valued).  An  example  of  a  built-in  attribute  is  the  delay  parameter  of  graph  edges. 

2.4  Parameters 

Parameterization  of  attribute  values  is  possible  in  DIF  with  the  params 
block.  The  capability  of  defining  a  possible  set  of  values  ( domain )  for  an  attribute 
instead  of  a  specific  value  provides  useful  support  for  dynamic  and  reconfigurable 
dataflow  graphs.  The  domain  of  a  parameter  can  be  an  enumerated  set  of  values,  an 
interval,  or  a  composition  of  both  forms. 

2.5  The  basedon  Feature 

Using  the  basedon  keyword,  a  graph  that  has  the  same  topology  as  another 
graph,  but  with  different  attribute  or  parameter  values  can  be  defined  concisely  with 
just  a  reference  to  the  other  graph.  The  user  can  change  selected  parameter  and 
attribute  values  by  overriding  them  in  attribute  and  params  blocks  of  the  new 
graph. 

2.6  Other  Language  Specifications 

The  DIF  language  employs  C-language  style  identifiers:  an  edge,  node,  port 
or  graph  identifier  should  start  with  a  non-digit  (an  alphabetic  character  or  the 
underscore)  and  can  be  followed  by  digits  or  non-digits.  Non-digits  are  defined  as 
the  combination  of  uppercase  and  lowercase  letters  and  the  underscore  character 
(‘_’).  Identifiers  are  unique  and  should  not  be  repeated  even  across  different  kinds  of 
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entities.  Exceptions  to  this  rule  are  subgraphs  and  subgraph  port  identifiers  in  sub¬ 
graph  declarations. 

In  the  present  version  of  DIF,  a  value  for  an  attribute  can  be  one  of  the  fol¬ 
lowing  four  types:  double,  double  matrix,  string,  and  list.  Double  matrices  are  spec¬ 
ified  in  the  row-by-row  fonn 

(al,  1  a\,2  •••  a\ ,n’  a2,  1  a2,2  •••  a2 ,n’  am,  1  am,  2  •"  am,rd ' 

For  example, 

(5  7,  2  2,6  8) 

specifies  the  3x2  matrix 


5  7 

2  2  • 

6  8 

Strings  are  specified  in  C-language  style,  allowing  the  ‘+’  operator  for  concatena¬ 
tion.  Fists  are  specified  in  the  fonn  [v^  v2,  ...,  vk\ ,  where  each  v-  is  a  double,  dou¬ 
ble  matrix,  string,  or  (nested)  list. 

2.6.1  Summary  of  Keywords 

Following  is  a  list  of  keywords  that  are  used  in  DIF  grouped  according  to  the 
parts  of  DIF  specifications  in  which  they  are  used.  The  DIF  language  is  case  sensi¬ 
tive,  and  therefore,  keywords  must  be  used  with  correct  case. 

•  Top  level  definition:  basedon,  graph,  dif,  sdf,  csdf,  singleRate,  hsdf. 

•  Topology  definition:  topology,  nodes,  edges. 

•  Interface  declaration:  interface,  input,  output. 

•  Subgraph  declarations:  refinement. 

•  Parameter  definitions:  params,  param,  domain. 

•  Attribute  definitions: 

•  User-defined:  attribute 

•  Built-in:  production,  consumption,  delay,  transfer. 

These  keywords  are  written  in  boldface  throughout  the  paper  for  emphasis. 
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3.  Dataflow  Support 


The  DIF  package  is  a  Java-based  software  package  for  DIF  that  is  being 
developed,  along  with  the  DIF  language,  at  the  University  of  Maryland.  Associated 
with  each  of  the  supported  dataflow  graph  types  is  an  intermediate  representation 
within  the  DIF  package  that  provides  an  extensible  set  of  data  structures  and  algo¬ 
rithms  for  analyzing,  manipulating,  and  optimizing  DIF  representations.  Also,  con¬ 
version  algorithms  between  compatible  graph  types  (such  as  CSDF  to  SDF  or  SDF 
to  single-rate  conversion)  are  provided.  Presently,  the  collection  of  dataflow  graph 
algorithms  is  based  primarily  on  well-known  algorithms  (e.g.,  algorithms  for  itera¬ 
tion  period  computation  [9],  consistency  validation  [12],  and  loop  scheduling  [3]), 
and  the  contribution  of  DIF  in  this  regard  is  to  provide  a  common  repository  and 
front-end  through  which  different  DSP  tools  can  have  efficient  access  to  these  algo¬ 
rithms.  We  are  actively  extending  this  repository  with  additional  dataflow  modeling 
features  and  additional  algorithms,  including  more  experimental  algorithms  for  data 
partitioning  and  hardware  synthesis.  Below  is  a  summary  of  the  dataflow  models 
that  are  currently  supported  in  DIF. 

3,1  DIF  Graphs 

DIF  graphs  are  the  default  and  most  general  class  of  dataflow  graphs  sup¬ 
ported  by  DIF.  DIF  graphs  can  be  specified  explicitly  using  the  dif  keyword.  In  DIF 
graphs,  no  restriction  is  made  on  the  rate  at  which  data  is  produced  and  consumed 
on  dataflow  edges,  and  other  types  of  specialized  assumptions,  such  as  statically- 
known  delay  attributes,  are  avoided  as  well.  In  the  underlying  intermediate  repre¬ 
sentation,  an  arbitrary  Java  object  can  be  attached  to  each  node/edge  incidence  to 
represent  the  associated  dataflow  properties.  In  the  inheritance  hierarchy  of  the  DIF 
intermediate  representations,  DIF  graphs  are  the  base  class  of  all  other  forms  of 
dataflow.  In  this  sense,  all  dataflow  graphs  modeled  in  DIF  are  instances  of  DIF 
graphs.  Furthermore,  if  a  tool  cannot  export  to  any  of  the  more  specialized  versions 
of  dataflow  supported  by  DIF,  it  should  export  to  DIF  graphs. 
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3.2  CSDF  Graphs 

In  restricted  versions  of  the  DIF  graph  model  that  are  recognized  in  DIF,  the 
number  of  data  values  (tokens)  produced  and  consumed  by  each  node  may  be 
known  statically  and  edge  delays  may  be  fixed  integers.  For  example,  CSDF  graphs, 
based  on  the  cyclo-static  dataflow  model  [4],  are  specified  by  annotating  DIF  graph 
definitions  with  the  csdf  keyword.  In  CSDF  graphs,  production  and  consumption 
rates  can  vary  between  node  executions,  as  long  as  the  variation  fonns  a  certain  type 
of  periodic  pattern.  Consequently,  values  of  these  rates  are  integer  vectors.  These 
vectors  are  associated  with  CSDF  graph  edges  using  the  production  and  consump¬ 
tion  keywords.  For  example,  the  code  fragment 

production  {el  [1  1  2  4];  e2  [2  2  3];} 
associates  the  periodic  production  patterns 

(1,  1,  2,  4,  1,  1,  2,  4,  ...)  and  (2,  2,  3,  2,  2,  3,  ...) 
with  edges  e  1  and  el ,  respectively. 

3.3  SDF  Graphs 

Similar  to  CSDF  graphs,  token  production  and  consumption  rates  of  syn¬ 
chronous  dataflow  (SDF)  graphs  [12]  are  known  at  compile  time,  but  they  are  fixed 
rather  than  periodic  integer  values.  SDF  graphs  are  specified  using  the  sdf  keyword, 
and  the  arguments  of  production  and  consumption  specifiers  in  SDF  graphs  are 
required  to  be  integers,  as  in: 

production  {el  4;  e2  3;} 
consumption  {el  5;  e2  2;} 

delay  {el  1 ;  e2  2;} 

The  last  statement,  which  is  pennissible  in  other  DIF  graph  types  as  well, 
associates  integer-valued  delays  to  the  specified  edges. 

3.4  Single-Rate  and  HSDF  Graphs 

Single-rate  graphs  are  a  special  case  of  SDF  graphs  in  which  the  production 
and  consumption  values  on  each  edge  are  identical.  In  single-rate  graphs,  nodes  exe¬ 
cute  (“fire”)  at  the  same  average  rate  [3].  In  the  slightly  more  restricted  case  of 
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homogeneous  SDF  (HSDF)  graphs,  production  and  consumption  values  are  equal  to 
one  for  all  edges.  Instead  of  production  and  consumption  attributes,  DIF  uses  the 
transfer  keyword  for  edges  in  single-rate  graphs.  DIF  does  not  associate  an  attribute 
for  token  transfer  volume  in  HSDF  graphs  since  it  is  not  variable. 

3.5  Parameterized  Dataflow  Graphs 

Parameterized  dataflow  [1]  graphs  can  be  represented  in  DIF  using  the 
parameterization  and  hierarchy  facilities  of  DIF.  Specifically,  separate  subgraphs 
can  be  defined  for  the  init,  submit,  and  body  subsystems  of  a  parameterized  dataflow 
model,  and  variable  parameters  with  associated  parameter  value  domains  can  be 
defined  and  linked  to  outputs  of  the  init  or  subinit  graphs  through  user-defined 
attributes. 

4.  DIF  Language  Implementation 


The  DIF  package  includes  a  parser  that  converts  a  DIF  specification  into  a 
suitable,  graph-theoretic  intermediate  representation  based  on  the  particular  form  of 
dataflow  used  in  the  DIF  specification.  This  parser  is  implemented  using  a  Java- 
based  compiler-compiler  called  SableCC  [7].  The  flexible  structure  of  the  compiler 
enables  easy  extensibility  for  different  graph  types. 

Using  DIF  writer  classes,  it  is  also  possible  to  generate  DIF  files  from  inter¬ 
mediate  representations  (graph  objects)  in  the  DIF  package.  The  default  writer  is  the 
DIF  graph  writer,  which  generates  a  DIF  graph  specification,  and  custom  writers  can 
be  constructed  by  extending  the  DIF  graph  writer  base  class  to  handle  semantic 
additions/restrictions  by  converting  them  to  appropriate  built-in  attributes,  structural 
conventions,  etc. 

The  DIF  package  builds  on  some  of  the  packages  of  Ptolemy  II  [11].  In  par¬ 
ticular,  the  attribute  features  of  DIF  are  built  on  the  rich  classes  for  managing 
attributes  in  Ptolemy  II,  and  the  intermediate  representations  of  DIF  build  on  the 
graph  package  of  Ptolemy  II,  which  provides  data  structures  and  algorithms  for 
working  with  generic  graphs. 
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5.  Examples 


This  section  illustrates  some  further  examples  of  the  utility  of  the  DIF  pack¬ 
age. 

5.1  Ptolemy 

We  have  developed  a  back-end  for  Ptolemy  II  that  generates  DIF  graphs 
from  dataflow-based  Ptolemy  II  models.  An  example  of  Ptolemy-to-DIF  conversion 
through  this  back-end  is  shown  in  Figure  3.  A  front-end  that  converts  DIF  specifica¬ 
tions  into  Ptolemy  II  models  is  under  development. 

5.2  MCCI  Autocoding  Toolset 

Another  usage  example  of  DIF  is  in  the  Autocoding  Toolset  of  Management, 
Communications,  and  Control,  Inc.  (MCCI)  [14].  This  tool  is  designed  for  mapping 
large,  complex  signal  processing  applications  onto  high-performance  multiproces¬ 
sor  platfonns.  Through  a  DIF-generating  back-end  developed  at  MCCI,  the  Autoc¬ 
oding  Toolset  supports  generation  of  DIF  specifications  after  partitioning  the 
application. 

Figure  4  shows  a  synthetic  aperture  radar  (SAR)  application  developed  in 
the  Autocoding  Toolset.  The  functional  requirements  of  SAR  processing  consist  of 
four  logical  processes:  data  input  and  conditioning,  range  processing,  azimuth  pro¬ 
cessing  and  data  output.  The  Autocoding  Toolset  partitions  the  application  into  five 
parts  dividing  the  azimuth  processing  into  two  parts.  Figure  4(a)  shows  the  top  level 
functional  definition  graph  and  Figure  4(b)  shows  the  range  subgraph.  DIF  defini¬ 
tions  of  these  graphs  can  be  found  in  Figure  5.  Range  processing  of  data  includes 
conversion  to  complex  floating  point  numbers,  padding  the  end  of  each  data  row 
with  zeros,  multiplying  by  a  weighting  function,  computing  the  FFT,  and  multiply¬ 
ing  the  data  by  the  radar  cross-section  compensation. 

5.3  Visualization  and  Benchmark  Generation 

The  DIF  package  contains  facilities  to  generate  DIF  specifications  of  ran¬ 
domly-generated,  synthetic  benchmarks.  This  can  be  useful  for  more  extensive  test- 
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ing  of  tools  and  algorithms  beyond  the  set  of  available  application  models.  The 
benchmark  generator  is  based  on  an  implementation  of  Sih’s  dataflow  graph  genera¬ 
tion  algorithm  [15],  which  constructs  application-like  graphs  by  mimicking  patterns 
found  in  practical  dataflow  models. 

DIF  specifications  and  intermediate  representations  can  also  be  converted 
automatically  into  the  input  format  of  dot  [10],  a  well-known  graph-visualization 


Random  Symbol  Source  Square  Root  Raised  Cosine  Pulse  Shaper 


e4  1 


sdf  graph  _graph  { 

consumption  { 

topology  { 

eO  1;  el  1; 

nodes { 

e2  1 ;  e3  1 ; 

nO,  n  1 ,  n2, 

e4  1; 

n3,  n4,  n5 

} 

} 

delay  { 

edges  { 

eO  0;  el  0; 

eO  nO  nl; 

e2  0;  e3  0; 

el  nl  n2; 

e4  0; 

e2  n2  n4; 

} 

e3  n3  n2; 

computation  { 

e4  n4  n5; 

nO  DiscreteRandomSource 

} 

nl  RaisedCosine; 

} 

n2  AddSubtract; 

production  { 

n3  Gaussian; 

eO  1;  el  16; 

n4  RaisedCosine; 

e2  1 ;  e3  1 ; 

n5  SequenceScope; 

Figure  3.  Ptolemy  II  model  of  a  PAM  communication  system  that  is  exported  to  DIF. 
This  example  represents  the  functionality  of  each  node  as  a  computation  attribute, 
which  is  derived  from  the  Ptolemy  II  library  definition. 
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tool.  Figure  6  shows  a  synthetic  DIFGraph  generated  by  the  DIF  package  and  laid- 
out  through  the  dot  generator. 

6.  Summary 

This  paper  has  presented  the  dataflow  interchange  format  (DIF),  a  textual 
language  for  writing  coarse-grain,  dataflow-based  models  of  DSP  applications,  and 
for  communicating  such  models  between  DSP  design  tools.  The  objectives  of  DIF 


(a) 


Figure  4.  (a)  The  top-level  partitioned  application  graph  of  a  SAR  application  in  the 
MCCI  Autocoding  Toolset,  (b)  Range  processing  graph. 
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graph  rangeGraph  { 
interface  { 

input  rngjn; 
output  rng  out; 

} 

topology  { 
nodes { 

pad:  rngjn, 

wght,  fft,  comp:rng_out 

} 

edges  { 

padded  pad  wght; 
weighted  wght  fft; 
compressed  fft  comp; 

} 

} 

production  { 

padded  1048576; 
weighted  1048576; 
compressed  1048576; 

} 

consumption  { 

padded  1048576; 
weighted  1048576; 
compressed  1048576; 

} 

delay  { 

padded  0;  weighted  0;  compressed  0; 

} 

} 


graph  SAR  { 

(b) 

refinement  { 

rangeGraph  range 

rngjn:in_sar  rng_out:out_rng; 

} 

} 

Figure  5.  (a)  Range  processing  in  DIF.  (b)  Range  processing  instantiation  in  SAR. 
Note  that  although  Figure  4(b)  represents  a  single-rate  graph,  the  Autocoding 
Toolset  presently  exports  this  in  the  more  general  form  of  a  DIF  graph.  This  exam¬ 
ple  is  adapted  due  to  space  constraints. 
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nO 


sdf  graph  _graph  { 
topology  { 
nodes { 

nO,  nl,  n2, 
n3,  n4,  n5, 
n6,  n7,  n8, 
n9,  nIO.nll, 
n12,  n13,  n14, 
n15,  n16,  n17, 
n18,  n19,  n20 


} 

edges  { 

eO  nO  nl 
el  nO  n2 
e2  nl  n3 
e3  n2  n5 
e4  n5  n4 


e31  n20  n13; 


} 

} 

production  { 

eO  1; 

e31  1; 

} 

consumption  { 

eO  1; 

e31  1; 

} 

delay  { 

eO  0; 

e31  0; 

} 


Figure  6.  A  synthetic  DlFGraph  generated  by  the  DIF  package  and  dot  generator 
output  for  the  graph. 
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are  to  accommodate  a  variety  of  dataflow-related  modeling  constructs,  and  to  facili¬ 
tate  experimentation  with  and  technology  transfer  involving  such  constructs.  We  are 
actively  extending  the  DIF  language,  including  the  set  of  supported  dataflow  model¬ 
ing  semantics,  and  the  associated  repository  of  intermediate  representations  and 
algorithms. 
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